• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    In order to make better use of the asynchronous bandwidth available in a real-time capable Ethernet data network protocol without collision, it is provided that at least one slave (S1,..., Sn) wishing to send asynchronous data to the master (M) in a transmission cycle (Z (m)) a request data packet (DPa) tells how many asynchronous data this slave (S1, ..., Sn) wants to send asynchronously and the master (M) by means of an invitation data packet (DPe) tells the slave (S1, ..., Sn), at which time (tas) within a following transmission cycle (Z (m + k + l)) the slave (S1, ..., Sn) is allowed to send the asynchronous data in an asynchronous data packet (DPas).
    公开号:AT517782A1
    申请号:T50832/2015
    申请日:2015-10-01
    公开日:2017-04-15
    发明作者:Dietmar Bruckner Dr；Prenninger Franz；Avramov Bernadette
    申请人:Bernecker + Rainer Industrie-Elektronik Ges M B H；
    IPC主号:
    专利说明:

    Method for asynchronous data communication in a real-time capable Ethernet
    Data network
    The subject invention relates to a method for asynchronous data communication in a real-time capable Ethernet data network, in which at least one master is connected via a switched Ethernet data network with a number of slaves and for Ethernet data communication, a transmission cycle is predetermined with a predetermined cycle time, the Split transmission cycle into an isochronous section and an asynchronous section and the real-time data communication is implemented in the isochronous section and the asynchronous section is used for data communication between master and slaves.
    In a data network for data communication, a network protocol is implemented, with which data in data packets on the data network are transmitted between the network nodes connected to the data network. The most well-known and widely used network protocol today is the Ethernet protocol. For this purpose, Ethernet defines data packets (also called data frame or Ethernet frame) in which data of a higher-level communication protocol can be transmitted encapsulated in an Ethernet data packet. In this case, data of the communication protocol with a data length between 46 and 1500 bytes can be transmitted in an Ethernet data packet. The addressing in the Ethernet protocol takes place via the MAC (Media Access Control) addresses of the network nodes, which are assigned uniquely for each network device. From the point of view of the known OSI layer model, Ethernet is implemented exclusively on layers 1 and 2. Different communication protocols can be implemented in the higher layers. Here, a variety of communication protocols have been established, such as IP on layer 3 or TCP and UDP on layer 4, to name a few widely used communication protocols.
    In terms of hardware, today's Ethernet systems are so-called switched data networks, in which individual network nodes do not have to be directly connected to each other and can not communicate directly with each other, but can be connected via coupling elements, so-called network switches or network hubs. A coupling element for this purpose has a number of network ports, to which a network participant (either a network node or another coupling element) can be connected. Such a coupling element forwards an Ethernet data packet either to all ports (hub) or to a specific port (s) (switch). Thus, in a switched data network so-called point-to-point connections are made in which Ethernet
    Data packets are forwarded from one network node via a number of coupling elements to another network node.
    Network nodes used in industrial automation often have a 3-port switch installed internally, whereby two ports are accessible from the outside and the third port is for internal wiring. This makes it possible to realize line topologies without additional external coupling elements, in which one network node is connected to the next network node in the form of a line, which helps reduce cabling costs in an industrial environment. Of course, external network switches or external network hubs can also be used to set up the network topology. In principle, any network topology is possible, that is to say in particular a star topology, a line topology, a tree topology, a ring topology, etc., and also any combination thereof. In a ring topology, as is generally known, special precautions must be taken to prevent the uncontrolled circulation of multiple-address data packets.
    In order to be able to use Ethernet for industrial automation, real-time-capable Ethernet protocols have already been developed since the standard Ethernet network protocol is not known to have real-time capability. Examples of well-known Ethernet network protocols include Modbus / TCP, EtherNet / IP, ProfiNET IRT, EtherCAT, or Ethernet POWERLINK, just to name a few. In this context one often speaks of Industrial Ethernet. These real-time-capable Ethernet protocols are intended to ensure sufficiently fast and deterministic data communication for the respective application. It is thus intended in particular to ensure that a real-time-relevant data packet is transmitted within a predetermined period of time by a transmitting network node via the network to a receiving network node. In an industrial automation environment, real-time capability means, for example, that a fixed period of time must be maintained between the acquisition of a measured value, forwarding of the measured value to a control unit, calculation of a control value in the control unit on the basis of the measured value and transmission of the control value to an actuator for carrying out an action. In relation to the real-time capable Ethernet data network for the transmission of this data via the real-time capable Ethernet data network, the data transmission must be ensured within a predetermined period of time.
    In an industrial automation environment, there is usually at least one master network node (in short, also a master), which communicates with at least one associated, generally several assigned, slave network node (in short, also slaves). To realize a real-time capable Ethernet data network, the known real-time capable Ethernet network protocols have defined a transmission cycle with a predefinable cycle time, within which the master can communicate with each slave. This normally includes cyclically the possibility of a data packet from the master to each slave and vice versa, also at least one data packet of a slave, usually at least one data packet from each slave, to the associated master. The achievable and previously ascertainable minimum cycle time results from the sum of the maximum runtimes of the data packets. The runtimes are essentially hardware-dependent and result from the bit transmission times (length, payload) of the data packets, from the network infrastructure (delay times through coupling elements) and the network topology. The above-mentioned limits in the size of the Ethernet data packets are also to be considered.
    In the specific implementation of this cyclic data traffic (also referred to as isochronous data traffic), the known real-time capable Ethernet protocols differ. For example, ProfiNET and Ethernet / IP send individual Ethernet data packets from the master to each slave and vice versa. By contrast, EtherCAT uses a pure summation frame method in which the master sends a data packet with data for all slaves to the first slave. This reads its data from the data packet and overwrites this data with data that the slave wants to send to the master. This changed data packet is then sent to the second slave, and so on, until the data packet is sent back to the master by the last slave in reverse order. In another known implementation of the summation frame method, the data packet is shortened from master towards the slaves by each slave takes its data from the data packet and extends in the reverse direction by each slave adds its data to the data packet to the master. Such a summary frame method is supported by ProfiNET IRT (Dynamic Frame Packing). EtherCAT and ProfiNET IRT, however, require special components to implement this cyclical data traffic and can not be implemented with standard Ethernet coupling elements. POWERLINK sends a data packet from the master as summation frame to all slaves, and the master receives a separate Ethernet data packet from each slave. POWERLINK can be operated with standard Ethernet coupling elements. The above-mentioned methods thus also differ substantially in the requirements of the hardware used.
    This cyclic (isochronous) traffic, which is the basis of real-time capability in the real-time capable Ethernet network protocol, is typically augmented by asynchronous (non-cyclic) data packets in each transmission cycle. Such asynchronous data packets are used by the data communication that is not subject to the real-time requirements, for example for the configuration of the slaves, for visualization purposes or for status queries. For such asynchronous data packets, bandwidth is reserved, i.e., a certain defined time is available for asynchronous data traffic in each transmission cycle. However, the network nodes must divide up this asynchronous section of a transmission cycle, for which there are different approaches in the known real-time-capable Ethernet protocols.
    Also in the implementation of asynchronous data traffic, therefore, the known real-time capable Ethernet protocols differ. ProfiNET allows arbitrary sending of asynchronous data packets using a prioritization to determine which asynchronous data packets are handled first. This allows the coupling elements to send higher-priority data packets faster and even to interrupt the transmission of low-priority data packets, if necessary, in order to prefer data packets of higher priority. However, this requires large data buffers in the coupling elements in order to be able to buffer data until it is sent in asynchronous data packets. In addition, the coupling elements thus also need some "intelligence" to make this prioritization, so that no standard coupling elements, such as a conventional Ethernet network switch, can be used. EtherCAT keeps an area for asynchronous data in the summation frame and the master indicates who is allowed to use this area. At POWERLINK, a slave is invited by the master to send asynchronous data. For both EtherCAT and POWERLINK, the slave signals the master in advance that it wants to send asynchronous data. This saves the data buffers in the coupling elements for asynchronous data.
    In the industrial automation environment based on real-time Ethernet network protocols, asynchronous bandwidth is becoming ever more important because on the one hand real-time capable Ethernet networks are becoming ever larger (in the sense of more and more network nodes), on the other hand the network nodes used offer more and more functions that are not cyclical must be called (eg web server, events, etc.). This also requires more asynchronous data traffic. However, the asynchronous bandwidth can not be increased arbitrarily, as this would increase the cycle time of a transmission cycle, which in turn would adversely affect the real-time capability.
    It is therefore an object of the present invention to specify a method with which the available asynchronous bandwidth of a real-time capable Ethernet network protocol can be better utilized collision-free for asynchronous data traffic.
    This object is achieved in that at least one slave that wants to send asynchronous data to the master in a transmission cycle by means of a request data packet tells how many asynchronous data this slave wants to send asynchronously and the master communicates to the slave by means of an invitation data packet at what time within a subsequent transmission cycle the slave is allowed to send the asynchronous data. The master thus controls all asynchronous data traffic on the part of the real-time capable Ethernet data network assigned to the master. Since the master not only knows that a slave wants to send asynchronous data, but also how many asynchronous data to send, the master can accurately plan and perform asynchronous data traffic while the data is being communicated. The available asynchronous bandwidth in each transmission cycle, which must be shared by the network nodes, can thus be optimally utilized. Tests with this method based on the POWERLINK Ethernet protocol have shown that (assuming otherwise identical prerequisites) the available asynchronous bandwidth can be better utilized on average by a factor between 5 and 10, ie with the method according to the invention between five and ten ten times as many asynchronous data can be sent as before.
    In addition, no data buffers are needed in the coupling elements for this method and it does not add any additional requirements to the Ethernet hardware. The method can thus also be used with commercially available internal and external coupling elements, e.g. conventional unmanaged network switches.
    The master can plan the asynchronous data traffic particularly flexibly if the master informs the slave with the invitation data packet in which of the following transmission cycles the slave is allowed to send the asynchronous data.
    It is particularly advantageous if the asynchronous data packet of the slave is sent in the transmission cycle, which follows immediately after the transmission cycle in which the slave has received the invitation data packet. This can increase the speed of asynchronous traffic by reducing the delay time between requesting and sending the asynchronous data packet. The delay time can be further reduced if the asynchronous data packet is sent in the transmission cycle in which the slave has received the invitation data packet.
    To be able to plan asynchronous data traffic even more flexibly, the master can tell the slave with the invitation data packet how many asynchronous data the slave is allowed to send. This also opens up the possibility of dividing the requested data size into several smaller asynchronous data packets.
    If the master tells the slave the data size in the invitation data packet, this can also be used to detect an error in the data communication. Then, the data size of the asynchronous data requested by the slave can easily be compared with the data size of the asynchronous data communicated by the master, and an error can be assumed in the event of a deviation.
    Preferably, the request data packet of the slave is sent in the isochronous section of the transmission cycle, because each slave has the opportunity in each transmission cycle to inform the master that he wants to send asynchronous data packets. This ensures that every slave gets the opportunity to send asynchronous data.
    The asynchronous data throughput can be further increased if the slave is allowed to send several request data packets before he has received an invitation data packet for his request, in particular if he is allowed to send several request data packets in one transmission cycle, since the slave so that several asynchronous data packets can also be sent in the following transmission cycles.
    It is particularly advantageous if the slave sends several asynchronous data packets in the following transmission cycle in order to be able to optimally utilize the available asynchronous bandwidth.
    Likewise, from the viewpoint of asynchronous data traffic, it is advantageous if the master sends the invitation data packet in the transmission cycle immediately following the transmission cycle in which the master has received the request data packet. This measure also helps to reduce the delay between request and send of the asynchronous data packet.
    Advantageously, the master also has the opportunity in a transmission cycle to send asynchronous data packets. Thus, asynchronous communication between the master and a slave, e.g. to operate a web server with active elements.
    The subject invention will be explained in more detail below with reference to Figures 1 to 5, which show by way of example, schematically and not by way of limitation advantageous embodiments of the invention. It shows
    3 shows an implementation of the asynchronous data communication according to the invention, FIG. 4 shows the asynchronous data communication according to the invention with a multicast data packet and FIG
    5 shows the sending of asynchronous data packets from the master to the slaves.
    The real-time-capable Ethernet network protocol on which the invention is based will be explained with reference to FIG. In this case, an exemplary network topology in the form of a line topology is used in which a master M is connected to a series of slaves S1... Sn connected in series to form a network. The slaves S1 ... Sn are designed here as network devices with integrated 3-port switch (coupling element), which allows such a line topology without external coupling elements. The master M can communicate with each slave S1 ... Sn in each transmission cycle Z, with a given cycle time tz, by sending Ethernet data packets DP (hereinafter referred to simply as data packets DP) on the Ethernet data network 1. A dispatched data packet DP is indicated in FIG. 1 as an arrow, the arrowhead indicating the transmission direction (ie from master M to a slave S or vice versa). Each horizontal line is assigned to a network node (master M or slaves S1... Sn) and represents a time stream. The network-related latency when transmitting the data packets DP via the Ethernet data network 1 is indicated by the oblique arrows, the processing duration of the data packets DP in the coupling elements and the latency are summarized by the finite propagation velocity in the medium (copper cable, optical fiber) and simplified as constant.
    A transmission cycle Z is precisely time-divided by the times tM, i, tM, 2, ·, tM, x, ts, i ..... ts, y are fixed, to which the master M or slaves S1 .. .N be allowed to send DP data packets. This data collisions on the Ethernet data network 1 can be avoided. After Ethernet allows full-duplex data communication, however, data packets DP can travel in both directions simultaneously on one network segment. In this way, each of the participating network nodes (master M, slaves S) knows at which time within a transmission cycle Z it is allowed to send data packets DP and when to receive data.
    These times t within the transmission cycle Z can be planned very precisely in advance if it is known how many data (bytes) are transmitted in a data packet DP. The larger the expected data packet DP, the farther apart are the time points t. If the data size is not known in advance, then a maximum data size, e.g. the maximum frame size of an Ethernet frame. Between two data packets DP, a given break must also be observed in each case.
    The number of network nodes, master M and slaves S1... Sn, and the size of the data sent is thus also decisive for the achievable cycle time tz.
    In Fig. 1, the master M in the transmission cycle Z (m) sends a data packet DP1 (m) to the last slave Sn. However, this data packet DP1 (m) could also be a summation frame which contains data for all slaves S1 ... Sn (indicated in the transmission cycle Z (m + 1)) and from which the slaves S1 ... Sn read their data. At a fixed time thereafter, the master M sends the next data packet DP2 (m), here e.g. to the slave S2. At the same time, the slave S2 can also send a data packet DP3 (m) to the master M. This principle is also observed by the remaining network nodes, whereby not every slave S1 ... Sn has to receive or send a data packet DP. However, the communication is advantageously planned by the specification of the times t such that the data packets DP from the slaves S1 ... Sn arrive at the master M in succession and without any time gap (apart from a pause to be maintained). This communication sequence is then repeated in the subsequent transmission cycles Z (m + i), whereby the same network nodes do not have to send or receive data packets DP in each transmission cycle Z, as indicated in FIG.
    This planned data communication takes place cyclically and it is provided in each transmission cycle Z a temporal portion tzyki for this isochronous traffic. However, in each transmit cycle Z, a section taSynch is also reserved for asynchronous data traffic, in which Ethernet data communication takes place, which need not meet any hard real-time requirements. If the cyclic communication differs from transmit cycle to transmit cycle (as exemplified in FIG. 1 between Z (m) and Z (m + 1)), then there is at least a maximum period duration (a transmit cycle) within which the transmit patterns will be exact repeat, d. H. the cyclic data packets in Z (m) are equal to those in Z (m + a). In each individual transmission cycle Z, however, the ratio between tzyki and taSynch may change, depending on the number of planned cyclic data packets.
    Of course, this communication principle also applies in other network topologies, as described with reference to FIG. 2 using the example of a star topology. Here, a star topology is constructed by means of an external network switch SW, wherein a line topology, as described in FIG. 1, is realized in each branch. The master M is also connected to the network switch SW. In the example shown, at the time tM, i at the beginning of each transmission cycle Z, a data packet DP1 (m) in the form of a sum frame is sent to all slaves S1... Sn. This data packet DP1 (m) is forwarded by the network switch SW in the two branches and there sent to all slaves S1 ... Sn. The other data packets DP are then sent back to the designated times tM, x, ts, y within the transmission cycle Z (m). However, it has to be considered here that the data packets DP, which are sent back to the master M by the slaves S1... Sn, are preferably to be planned in such a way that no data jams can arise in the master M and in the intervening network switch SW. The timing of the data packet DP2 (m) from the slave Sn to the master M is e.g. so planned that this data packet DP2 (m) does not collide with other data packets from the other branch of the star topology, as shown in FIG. The between master M and network switch SW reciprocating data packets DP are shown for clarity in Fig.2 only partially.
    The method according to the invention for asynchronous data communication is explained below with reference to FIG. Here, without restricting the generality, it is again assumed that a simple line topology is used as in FIG. In the cyclic section tzyk | the transmission cycle Z (m) takes place again the above-described, timed isochronous data communication. For the asynchronous data communication, a request data packet DPa is now provided in the cyclic section of the network protocol with which a slave S informs the master M that he would like to send asynchronous data. In the request data packet DPa, the slave simultaneously notifies how many asynchronous data (bytes) it has to send. Of course, several slaves S can send such request data packets DPa in one transmission cycle Z (m). In the example according to FIG. the slaves S2 and Sn such a request data packet DPa.
    The master M now collects these request data packets DPa and evaluates them. In this case, the master M can also collect and evaluate request data packets DPa of several consecutive transmission cycles Z. The evaluation takes place in such a way that the master M calculates which slaves S1 ... Sn are allowed to send their asynchronous data within a transmission cycle Z at which times tas. The master M can accurately plan the available asynchronous time period within the transmission cycle Z, because he knows which data packet sizes the slaves S1 ... Sn will send isochronously and want to send asynchronously.
    The priority control, that is, which slave data packets may send DP if there are more requests than available bandwidth, is completely in the master M. The priority of the individual asynchronous data packets DP of a slave S, however, are the responsibility of the slave S itself, i. each slave S decides which of its asynchronous data to send first. The master M processes the requests of each slave S preferably in order.
    After evaluating the requests, the master M sends in one of the next transmission cycles Z (m + k) an invitation data packet DPe to the slaves S1 ... Sn, which it loads to send asynchronous data. Preferably, the master M can also send the invitation data packet DPe in the immediately next transmission cycle Z (m + 1), ie k = 1, after it has received request data packet (s) DPa in the transmission cycle Z (m).
    In the invitation data packet DPe is included in which transmission cycle Z (m + k + l) and at which time tas within this transmission cycle Z (m + k + l) each slave S1 ... Sn may send its asynchronous data. If, after receipt of the invitation data packet DPe, the asynchronous data are always sent in the immediately following transmission cycle Z (m + k + 1) or always in the next l-th transmission cycle Z (m + k + 1), then in the invitation data packet DPe this must be sent Information is not necessarily included. It is advantageous in this context if the asynchronous data are always sent in the immediately next transmission cycle Z (m + k + 1), ie 1 = 1. It is particularly advantageous in this case if the asynchronous data are still sent in the same transmission cycle Z (m + k) in which the invitation data packet DPe was received, ie l = 0.
    The invitation data packet DPe can advantageously be implemented as a sum frame (as indicated in FIG. 3) in which S1 ... Sn is contained for each slave, in which transmission cycle Z (m + k + 1) and within this transmission cycle Z (m + k + l) is allowed to send its asynchronous data.
    The invitation data packet DPe can be sent at any (but fixed) point in the transmission cycle Z (m + k) and does not necessarily have to be sent at the beginning of a transmission cycle Z (m + k), as shown in FIG. In particular, the input data packet DPe can also be sent in the asynchronous section taSynch and also at the end of the transmission cycle Z (m + k). Likewise, several invitation data packets DPe can also be sent in a transmission cycle Z (m + k).
    In the example according to FIG. 3, the master sends the invitation data packet DPe in the transmission cycle Z (m + k) at time tM, i, here in the form of a summation frame, with which it notifies the slaves S2, Sn in which transmission cycle Z (m + k + l) and at what time tas> 2, tas> n, tas, nn within this transmission cycle Z (m + k + l) these asynchronous data asynchronous data packet in an asynchronous data packet DPas, here asynchronous data packets DPas2, DPasn, DPasnn , allowed to ship.
    The master M can also tell the slaves S2, Sn how much data may be sent asynchronously. Thus, a slave S can be requested to send only part of the requested asynchronous data. For the remaining data, the salve S can then again send a request data packet DPa. However, communicating the size of the data can also be used for error detection. If a slave S receives an invitation for a data size that does not correspond to his request, the slave can start from an error and send a new request data packet DPa and thus also signal to the master M that an error has occurred.
    In this case, it should be noted that the master M preferably plans the asynchronous data communication to avoid collisions with the isochronous data traffic so that the asynchronous data from the slaves S1 ... Sn arrive in the asynchronous section tasynch at the receiver, here the master M. This means that a slave Sn may also send an asynchronous data packet DPasn in the cyclic section tzyk of the transmission cycle Z (m + k + 1) if this does not result in collisions in the Ethernet data network 1, as shown in FIG.
    It is also possible that a slave Sn in a transmission cycle Z (m + k + l) also several times asynchronous data packets DPasn, DPasnn sent, as shown in Figure 3, if that goes out within the available asynchronous bandwidth. Thus, e.g. also large asynchronous data DPas be sent from a slave S to the master M.
    Basically, data packets DP are possible in the Ethernet network protocol, which are to be sent from a slave S to several other network nodes, master M or slaves S1 ... Sn, a so-called multicast data packet DPmc. This essentially also applies to asynchronous data communication. However, when planning asynchronous data communication, the master M does not know by itself whether a slave that has logged on a request for asynchronous data traffic wants to send a multicast data packet DPmc, or wants to send the asynchronous data only to the master M. A slave S1 ... Sn could now inform the master M in the request data packet DPa that it would like to send a multicast data packet DPmc. Or the master M always takes into account the possibility of multicast data packets DPmc in the planning of asynchronous data communication. In any case, the master M plans the asynchronous data communication so that there are no collisions on the Ethernet data network 1.
    FIG. 4 shows the sending of an asynchronous multicast data packet DPmc, where the entire history already described, that is to say request data packet DPa and invitation data packet DPe, has been omitted for the sake of simplicity. In this example, the master M has scheduled the time tmc for the multicast data packet DPmc so that there are no collisions in the Ethernet data network 1 and that the multicast data packet DPmc in the asynchronous portion tasynch the transmission cycle Z (m + k + l ) arrives at the master M.
    Likewise, of course, the master M itself asynchronous data packets DPasm to the slaves send S1 ... Sn, as shown in Figure 5. Here, too, the master M must plan the transmission times tM of these asynchronous data packets DPasm such that they arrive within the asynchronous section taSynch of the transmission cycle Z (m) at the receiver, in this case the (or one or a group of) slaves S1 ... Sn , The asynchronous data packets DPasm of the master M can also be used within the cyclic section tzyk | be sent.
    The planning of the asynchronous data traffic in the master M could, for example, proceed as follows.
    If the master M knows that all slaves S1 ... Sn only want to send asynchronous data packets DPas to him and there is no data traffic between the slaves S1 ... Sn (without master M), it is sufficient that the transmission times tas the asynchronous Data packets DPas of the slaves S1 ... Sn to be calculated so that, taking into account the known topology-dependent maturities of the asynchronous data packets DPas through the Ethernet data network 1 they arrive as possible with no gap at the master M. Since the master M is the isochronous communication in the cyclic section tzyk | knows, he has a list of free slots within a transmission cycle Z (m + k + l), which he can plan for asynchronous data traffic.
    In all other cases, the master M must check on all connections of the known network topology, whether at runtime of the asynchronous data packet DPas, DPasm no other data packet DP, synchronous or asynchronous, already scheduled in the same direction, and possibly the asynchronous data packet DPas, DPasm in time move accordingly.
    These runtime computations are quite simple arithmetic tasks (in essence, runtimes are added) that can be calculated easily and without much computation in the master M because the master M knows the network topology and the individual runtimes at the junctions between the network nodes.
    The master M can also take into account a maximum size of an asynchronous data packet DPas, DPasm. The maximum size results from the fact that a data packet DPas, DPasm may only be so large that this asynchronous data packet DPas, DPasm can be sent in a transmission cycle Z from any network node to any other network node. If necessary, an asynchronous data packet DPas, DPasm must also be split over several data packets if the asynchronous data to be sent is too large.
    The slaves S1... Sn can request asynchronous transmission slots from the master M by means of request data packets DPa until they are actually assigned a transmission slot in a transmission cycle Z by the master M by means of invitation data packets DPe. Advantageously, the slaves S still send a consecutive number with each request data packet DPa. As a result, a slave S can send several different requests to the master M even before the invitation for the first asynchronous data packet DPas arrives again at the slave S.
    By continually repeating all pending requests, Master M and Slave S are able to detect errors and, if necessary, restart the request invitation process, e.g. after a number of unsuccessful attempts.
    权利要求:
    Claims (14)
    [1]
    claims
    1. A method for asynchronous data communication in a real-time capable Ethernet data network (1), in which at least one master (M) via the Ethernet data network (1) with a number of slaves (S1, Sn) is connected and for the Ethernet data communication a transmission cycle (Z) with predetermined cycle time (tz) is given, wherein the transmission cycle (Z) is divided into an isochronous section (tzyki) and an asynchronous section (tasynch) and the real-time data communication in the isochronous section (tZyki) is implemented and the asynchronous section (tasynch) is used for asynchronous data communication between master (M) and slaves (S1, Sn), characterized in that at least one slave (S1 ..... Sn) wishing to send asynchronous data to the master (M) in a transmission cycle (Z (m)) by means of a request data packet (DPa) tells how many asynchronous data this slave (S1, ..., Sn) would like to send asynchronously and the master (M) by means of an invitation D Data packet (DPe) tells the slave (S1, Sn), at which time (tas) within a following transmission cycle (Z (m + k + l)) the slave (S1 ..... Sn) the asynchronous data in an asynchronous Send data packet (DPas).
    [2]
    2. The method according to claim 1, characterized in that the master (M) tells the slave (S1, ..., Sn) with the invitation data packet (DPe), in which of the following transmission cycles (Z (m + k + l )) the slave (S1, ..., Sn) is allowed to send the asynchronous data.
    [3]
    3. The method according to claim 1, characterized in that the asynchronous data packet (DPas) of the slave (S1 ..... Sn) in the transmission cycle (Z (m + k)) is sent, in which the slave (S1, .. ., Sn) has received the invitation data packet (DPe).
    [4]
    4. The method according to claim 1, characterized in that the asynchronous data packet (DPas) in the transmission cycle (Z (m + k + 1)) is sent, which follows directly on the transmission cycle (Z (m + k)), in which Slave (S1, ..., Sn) has received the invitation data packet (DPe).
    [5]
    5. The method according to any one of claims 1 to 4, characterized in that the master (M) the slave (S1, ..., Sn) with the invitation data packet (DPe) tells how many asynchronous data of the slave (S1, ..., Sn) may ship.
    [6]
    6. The method according to claim 5, characterized in that an error in the Ethernet data communication is detected when the requested by the slave (S1 ..... Sn) data of the asynchronous data and the master (M) shared data size of the asynchronous data.
    [7]
    7. The method according to any one of claims 1 to 4, characterized in that the request data packet (DPa) of the slave (S1, Sn) in the isochronous portion (tzyki) of the transmission cycle (Z (m)) is sent.
    [8]
    8. The method according to any one of claims 1 to 7, characterized in that the slave (S1, ..., Sn) in the transmission cycle (Z (m)) a plurality of request data packets (DPa) shipped.
    [9]
    9. The method according to any one of claims 1 to 8, characterized in that the slave (S1, ..., Sn) in the following transmission cycle (Z (m + k + l)) a plurality of asynchronous data packets (DPas) sends.
    [10]
    10. The method according to any one of claims 1 to 9, characterized in that the invitation data packet (DPe) in the transmission cycle (Z (m + 1)) is sent, which follows directly on the transmission cycle (Z (m)), in the the master (M) has received the request data packet (DPa).
    [11]
    11. The method according to any one of claims 1 to 10, characterized in that the invitation data packet (DPe) in the transmission cycle (Z (m)) is sent, in which the master (M) has received the request data packet (DPa).
    [12]
    12. The method according to any one of claims 1 to 11, characterized in that the master (M) the slave (S1, ..., Sn) in a transmission cycle (Z (m + k)) a plurality of invitation data packets (DPe) sends ,
    [13]
    13. The method according to any one of claims 1 to 12, characterized in that in a transmission cycle (Z (m), Z (m + k), Z (m + k + l)) additionally from the master (M) an asynchronous data packet ( DPasm) is sent to at least one slave (S1, ..., Sn).
    [14]
    14. The method according to any one of claims 1 to 13, characterized in that an error in the Ethernet data communication is detected when the slave (S1 ..... Sn) to a request data packet (DPa) no invitation data packet ( DPe) from the master (M).
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3183851B1|2017-10-25|Distribution node, automation network, and method for transmitting real-time-relevant and non-real-time relevant data packets
    EP3038325A1|2016-06-29|Method for transmitting data in a communications network of an industrial automation system and coupling communication device
    EP1826646B1|2011-01-05|Method, node and network for cyclical transmission of ethernet telegrams
    EP3522482B1|2020-08-26|Method for communicating data in an industrial network , control method, device, computer program and computer-readable medium
    EP2137893B1|2013-06-26|Packet switching device and local communication network with such a packet switching device
    DE102013207826B3|2014-07-17|Method for operating a slave node of a digital bus system
    EP3151474B1|2018-09-05|Method for data communication with reduced overhead in a real-time ethernet data network
    EP3151475B1|2018-06-06|Method for asynchronous data communication in a real-time ethernet data network
    WO2015031926A1|2015-03-12|Method for transmitting messages in a computer network and computer network
    DE10004425A1|2002-01-17|Network with subscriber device, esp. field device, enables transmitter, receiver transmission, reception time delays to be taken into account for time synchronisation
    EP3151492B1|2018-06-06|Method for data communication with reduced overhead in a real-time ethernet data network
    WO2015164897A1|2015-11-05|Method for flexibly controlling time-controlled data flows in a distributed computer system
    EP3151476B1|2021-06-30|Method for cross-traffic between two slaves of a ring -shaped data network
    EP2827207A1|2015-01-21|Method for transmitting data frames by means of a communication device of an industrial automation system and communication device
    EP2920923B1|2019-09-18|Method and computer network for the transmission of real-time messages
    EP1436950B1|2008-04-23|User device for a high performance communication system
    EP3151473B1|2020-06-17|Method for isochronous data communication in a real-time cable ethernet data network
    DE102015222848B4|2020-03-26|System and method for analyzing a network
    EP3410645A1|2018-12-05|Method for operating acommunication network of an industrial automation system and coupling communication device
    DE10004426A1|2001-08-09|Network participants, in particular field device, and network with such a network participant
    DE10234148A1|2003-05-08|Participant for a high-performance communication system
    DE102008007130A1|2009-08-06|Communication system for use in motor vehicle, has terminals and switching devices arranged such that transmission of data packets from terminals to device or viceversa is implemented in asynchronous and synchronous manner, respectively
    同族专利:
    公开号 | 公开日
    EP3151475B1|2018-06-06|
    CA2943875A1|2017-04-01|
    AT517782B1|2021-10-15|
    US10389806B2|2019-08-20|
    EP3151475A1|2017-04-05|
    US20170099351A1|2017-04-06|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    EP0584820A1|1992-08-27|1994-03-02|Nec Corporation|Access system|
    EP0827308A2|1996-08-30|1998-03-04|Hewlett-Packard Company|Shared communications channel|
    WO1998026515A1|1996-12-12|1998-06-18|Airdata Wiman, Inc.|Method for transmission of data packets|
    KR100294553B1|1997-01-24|2001-07-31|모리시타 요이찌|Communication Network|
    WO2003028289A2|2001-09-26|2003-04-03|Siemens Aktiengesellschaft|Method for transmitting real time data messages in a cyclic communications system|
    US20030214953A1|2002-05-14|2003-11-20|Ge Medical Systems Global Technology Company, Llc|Networked magnetic resonance imaging system and method incorporating same|
    JP4178552B2|2003-07-24|2008-11-12|株式会社安川電機|Master-slave synchronous communication method|
    US7941660B2|2003-11-13|2011-05-10|Gemalto Sa|System and method for data communications allowing slave device to be network peers|
    DE102005060085B9|2005-12-15|2010-09-30|Beckhoff Automation Gmbh|Method, communication network and control unit for the cyclic transmission of data|
    AT537632T|2006-03-29|2011-12-15|Yamaha Corp|AUDIO NETWORK SYSTEM|
    KR101126896B1|2007-11-21|2012-03-20|미쓰비시덴키 가부시키가이샤|Communication device, band allocation method, and slave station device|
    AR073128A1|2008-08-26|2010-10-13|Spx Corp|DIGITAL OSCILLOSCOPE MODULE|
    US9021292B2|2011-05-20|2015-04-28|Texas Instruments Incorporated|Method and system for asynchronous serial communication in a ring network by generating an oversampling clock using a fractional rate multiplier and sampling a received data bit sequence that includes voltage and temperature information in a battery management system|
    US9946680B2|2012-10-05|2018-04-17|Analog Devices, Inc.|Peripheral device diagnostics and control over a two-wire communication bus|
    US8832342B2|2011-10-28|2014-09-09|Lg Cns Co., Ltd.|Traffic communication module and method of forming the same|
    DE102011085764A1|2011-11-04|2013-05-08|Robert Bosch Gmbh|Method for operating a bus arrangement|
    DK2856688T3|2012-05-31|2019-07-15|Sonova Ag|MENU SLAVE DATA TRANSMISSION SYSTEM BASED ON A FLEXIBLE SERIAL BUS FOR HEARING APPLIANCES|
    DE102012210243B4|2012-06-18|2017-12-28|Siemens Aktiengesellschaft|Method for transmitting data packets in a communication network and communication network|
    US20150102943A1|2013-10-10|2015-04-16|Datang Nxp Semiconductors Co., Ltd.|Daisy-chain communication bus and protocol|DE102017130547A1|2017-12-19|2019-06-19|Volkswagen Aktiengesellschaft|Method for sending data packets, control unit and system with control unit|
    US10833987B2|2019-01-29|2020-11-10|Cisco Technology, Inc.|Supporting asynchronous packet operations in a deterministic network|
    法律状态:
    优先权:
    申请号 | 申请日 | 专利标题
    ATA50832/2015A|AT517782B1|2015-10-01|2015-10-01|Method for asynchronous data communication in a real-time capable Ethernet data network|ATA50832/2015A| AT517782B1|2015-10-01|2015-10-01|Method for asynchronous data communication in a real-time capable Ethernet data network|
    EP16191513.7A| EP3151475B1|2015-10-01|2016-09-29|Method for asynchronous data communication in a real-time ethernet data network|
    US15/281,719| US10389806B2|2015-10-01|2016-09-30|Method for asynchronous data communication in a real-time capable ethernet data network|
    CA2943875A| CA2943875A1|2015-10-01|2016-09-30|Method for asynchronous data communication in a real-time capable ethernet data network|
    [返回顶部]